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I. REAL PARTY IN INTEREST 

The real party in interest is Electronics For Imaging, Inc., a Delaware 
corporation having a place of business at 303 Velocity Way, Foster City, CA 94404. 

II. RELATED APPEALS AND INTERFERENCES 

None. 

III. STATUS OF CLAIMS 

1-22 Cancelled 
23-38 Rejected. 

IV. STATUS OF AMENDMENTS 

None. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The claimed subject matter pertains to systems and methods for forming a 
contract for completing a print job. (Page 2, lines 5-7; page 5, lines 2-7; page 6, 
lines 3-7; page 9, lines 1-7). 

Independent Claim 23 

Independent claim 23 recites a computer-based contracting method 

comprising: 

receiving a user-supplied set of constraints regarding a print job project 
(page 10, lines 15-19; page 16, lines 7-16; page 19, lines 2-7; page 21, lines 1-8; page 
23, lines 13-19; page 26, lines 5-18); 

storing the set of constraints in a database as an object (page 10, lines 3-5; 
page 16, lines 9-11; page 19, lines 3-7; page 23, lines 20-21); 

creating a plurality of instances of the object, each instance uniquely 
associated with a corresponding vendor (page 20, lines 1 1-13; page 23, lines 21-23); 
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communicating each instance of the object to its corresponding associated 
vendor (page 24, lines 8-10; page 24, line 20 through page 25, line 7); 

receiving communications from the user and the vendors to iteratively 
modify the instances of the object, the modifications further constraining the print job 
project (page 10, lines 1 1-14; page 10, lines 15-20; page 11, lines 1-9; page 17, lines 6- 
1 1; page 17, lines 15-22; page 26, line 21 through page 27, line 2); 

selectively displaying to the user the modified instances of the object 
individually or collectively (page 19, lines 13-18; page 20, lines 17-21; page 25, lines 
15-19; page 26, lines 20-23); and 

receiving a selection from the user of one of the vendors to complete the 
print job project (page 1 1 , lines 7-11; page 18, lines 4-6; page 22, lines 10-12; page 27, 
lines 4-6). 

Independent Claim 31 

Independent claim 3 1 recites a system for facilitating the formation of a 
contract for completing a print job project, the system comprising: 

a user interface adapted to receive a user-supplied set of constraints 
regarding the print job project (page 10, lines 15-19; page 16, lines 7-16; page 19, 
lines 2-7; page 21, lines 1-8; page 23, lines 13-19; page 26, lines 5-18); 

a database comprising a plurality of objects, each object comprising the set 
of user-supplied constraints, each object uniquely associated with a corresponding 
vendor (page 10, lines 3-5; page 16, lines 9-11; page 19, lines 3-7; page 20, lines 1 1-13; 
page 23, lines 20-23;); 

a plurality of vendor interfaces, each vendor interface uniquely associated 
with a corresponding vendor and adapted to communicate each associated object to its 
corresponding vendor (page 10, lines 20-24; page 16, lines 21-23; page 19, line 21 
through page 20, line 2; page 24, lines 8-10; page 24, line 20 through page 25, line 7); 
and 

a web server adapted to (a) transmit communications between the user and 
the vendors to iteratively modify the objects, the modifications further constraining the 
print job project, (b) selectively display to the user the modified instances of the objects 
individually or collectively; and (c) receive a selection from the user of one of the 
vendors to complete the print job project (page 10, lines 1 1-14; page 10, lines 15-20; 
page 11, lines 1-1 1; page 17, lines 6-11; page 17, lines 15-22; page 18, lines 4-6; 
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page 18, line 23 through page 19, line 2; page 19, lines 13-18; page 20, lines 2-5; 
page 20, lines 9-11; page 20, lines 17-21; page 20, line 23 through page 22, line 14; 
page 25, lines 15-19; page 26, line 20 through page 27, line 6). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether Claims 23-38 are unpatentable under 35 U.S.C. § 103(a) as 
obvious over Thackston, U.S. Patent No. 6,295,513 ("Thackston"), in view of Hill U.S 
Patent No. 5,970,471 ("Hill"), and further view of Huberman U.S. Patent No. 5,826,244 
("Huberman"). 

VII. ARGUMENT 

Rejection Under § 103(a) Over Thackston, Hill and Huberman 

Claims 23-38 

A. Summary of Examiner's Rejections 
The Examiner has asserted that: 

1 . Thackston teaches using web browser templates to submit an "RFQ 
form," and that the RFQ form includes constraints, such as quantity requirements, etc. 
(8 November 2006 Final Office action "Final Action" at 3-4 and 8). 

2. The RFQ forms/templates are stored as objects in an object-oriented 
database. (Final Action at 4 and 8-9). 

3. In response to receiving the user's RFQ with a set of constraints, the 
vendors' "responses and iterative responses [to the RFQ] . . . correspond to creating a 
plurality of instances wherein each instance is uniquely associated with a corresponding 
vendor." (Final action at 4 and 8). 

4. Thackston' s disclosure of "negotiation process" would have taught 
and fairly suggested the "claimed iterative plurality of customer submission instances 
and vendor responses instances communicating them back and forth to clarify the terms 
and parameters of the goods and/or services." (Final Action at 4 and 9). 

5. Thackston discloses conducting negotiations by using a series of 
contract templates as a starting point for contractors and suppliers for creating an 
agreement. (Final Action at 4 and 9). 
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6. The term "negotiations" as used by Thackston means "conducting to 
and fro discussions between the parties that is between the contractors and suppliers in 
order to reach an agreement or sign a contract." (Final Action at 4). 

7. "[T]he negotiation process of such repetitive discussions . . . 
correspond to ' a plurality of iterative customer submission instances and vendor 
response instances Tl and ' an iterative process in which one or more constraints on one 
of the vendor specific instances of the print job request object are added, removed 
and/or modified during each iteration' in claims 23 and 3 1 ." (Final Action at 5 and 9- 
10) (emphasis added). 

8. Huberman teaches a system and method to enable ordering and 
negotiating a print job on an electronic network, and Hill "teaches comparing vendor 
specific instances in a combined view, that is collectively." (Final Action at 10-1 1). 

B. Discussion of Thackston 

Thackston describes a computer-based system and method for undertaking 
an engineering design and development effort, identifying qualified fabricators for 
manufacturing a part design, and conducting a virtual bidding process for selecting a 
fabricator to manufacture the part. (Abstract; Col. 1, lines 19-29; Col. 4, lines 28-50). 
In particular, Thackston' system includes: (1) a collaborative engineering feature 
(referred to as "NICECAD"); (2) a global manufacturer's registry feature (referred to as 
"GMR"); and (3) an electronic bidding capability feature (referred to as "ETC"). 
(Col. 4, lines 51-65; Col. 5, lines 30-47; Col. 5, line 55 through Col. 6, line 5; Col. 6, 
lines 53-63; Col. 8, lines 45-57). 

The NICECAD system 100 includes a NICECAD server system 200, 
coupled via network 260 to databases 210, prime contractor user systems 220 and 
supplier user system 230. (Col. 9, lines 18-24; Col. 11, lines 25-29; FIG. 2). 
NICECAD server system 200 includes, among other things, software modules for 
computer-aided design ("CAD"), engineering analysis and simulation ("EAS"), 
multimedia communications and electronic commerce ("EC"). (Col. 8, lines 61-65; 
Col. 9, lines 1 1-17; Col. 11, lines 46-49; Col. 18, lines 33-38). In particular, NICECAD 
server system 200 includes multimedia communications processing module 978 and 
electronic commerce processing module 988. (FIG. 9). 

Multimedia communications processing module 978 provides multimedia 
communications capabilities for the system, and may be used by design team members 
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when developing and evaluating a part design, and by a prime contractor for engaging 
in quasi-real-time discussions with fabricators regarding design and/or contractual 
issues. (Col. 24, lines 28-36; Col. 28, lines 5-57). Electronic commerce processing 
module 988 includes standard contracts processing module 1402 that permits users 
(such as a prime contractor and a supplier or fabricator) to access standard form contract 
"templates" from standard contracts data module 696 that may be used as a starting 
point for creating an agreement, such as an agreement for a fabricator to produce design 
prototypes. (Col. 12, line 66 through Col. 13, line 24; Col. 25, lines 26-46; Col. 29, 
lines 44-48). 

After using the NICECAD system to create a part design, a prime 
contractor/designer then may use the ETC feature of the system to electronically solicit 
a request for quote ("RFQ") to fabricators for out-sourcing the manufacture of the part. 
(Col. 48, lines 26-51). The RFQ includes design and specification data for the part. 
(Col. 48, lines 61-64). The fabricators may submit bids in response to the RFQ, and the 
prime contractor/designer may evaluate the bids and then select one or more fabricators 
for contract negotiation and contract award. (Col. 5 1 , lines 9-30). In this regard, with 
the aid of the system's multimedia capabilities, the prime contractor and the selected 
fabricators may use and the system's standard clauses to negotiate a part's procurement 
contract. (Col. 51, lines 30-60). 

C. Discussion of Huberman 

Huberman describes a system and method for an electronically networked 
brokered auction for document services. (Abstract; Col. 2, lines 54-58). In particular, a 
set of one or more customer processes 210 is coupled via broker process 230 to a set of 
one or more supplier processes 220. (col. 7, line 66 through Col. 8, line 5). Broker 
process 230 conducts auctions for document services, and facilitates transactions related 
to the services between customer processes 210 and supplier processes 220. (Col. 3, 
lines 52-58; Col. 4, lines 19-23; Col. 8, lines 5-13). 

For example, a customer process 210a generates a job request that specifies 
particulars for a document service that will be the subject of an auction. (Col. 10, lines 
6-9). After receiving the job request from customer process 21 0a, broker process 230 
can conduct an auction for the requested document service. (Col. 10, lines 22-24). To 
do so, broker process 230 informs supplier processes 220 that an auction will be 
conducted for the requested document service, such as by broadcasting the particulars of 



6 



the job request via network 100. (Col. 10, lines 24-29). Broker process 230 then opens 
the bidding and begins to accept bids from supplier processes 220. (Col. 10, lines 29- 
35). Broker process 230 continues to accept bids until an ending criterion for the 
auction has been met. (Col. 11, lines 16-25). Broker process 230 then determines if 
any supplier process 220 won the auction, and also determines the prices associated 
with the winning bids, and automatically generates a proposed transaction. (Col. 11, 
line 26 through Col. 12, lines 43). Broker process 230 communicates the proposed 
transactions to customer process 210a. (Col. 12, lines 44-47). After evaluating the 
proposed transactions, customer process 210a communicates the customer's response to 
broker process 230 via network 100. (Col 12, line 44 through Col. 13, line 10). If the 
customer accepts the proposed transaction, broker process 230 notifies the winning 
supplier process 220 via network 100, and the transaction can then proceed. (Col. 13, 
lines 14-17). 

D. Discussion of Hill 

Hill describes a virtual product catalog for presenting a plurality of product 
images for review by a user on a computer. (Abstract; Col. 1, lines 6-12). 

E. Discussion of the § 103(a) Rejections 

The Final Action fails to establish a prima facie case of obviousness because 
none of the cited references, alone or combined, describe or suggest systems or methods 
that receive a user-supplied set of constraints regarding a print job project, store the set 
of constraints in a database as an object, create a plurality of instances of the object, 
each instance uniquely associated with a corresponding vendor, and communicate each 
instance of the object to its corresponding associated vendor. In addition, none of the 
cited references, alone or combined, describe or suggest selectively displaying to the 
user modified instances of the object individually or collectively 

The Final Action at 3-4 states that Thackston teaches using web browser 
templates to submit an "RFQ form," and that the RFQ form includes constraints, such 
as quantity requirements, etc. Thus, the Examiner suggests (without expressly stating) 
that the RFQ form constitutes the claimed user-supplied set of constraints regarding a 
print job project. Claim 23 recites storing the user-supplied set of constraints in a 
database as an object, and creating a plurality of instances of the object, each instance 
uniquely associated with a corresponding vendor. Claim 31 recites a database 
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comprising a plurality of objects, each object comprising the set of user-supplied 
constraints, each object uniquely associated with a corresponding vendor. Thus, based 
on the Examiner's interpretation, Thackston should disclose storing the RFQ in a 
database as an object, and creating a plurality of instances of the RFQ, each instance 
uniquely associated with a corresponding vendor. Thackston does not, however, 
describe or suggest anything of the sort, and the Examiner has failed to identify any 
such description or suggestion. 

Instead, the Final Action at 4 states that the vendors' responses and iterative 
responses to the RFQ correspond to "creating a plurality of instances wherein each 
instance is uniquely associated with a corresponding vendor" (emphasis added). First, 
the claims do not recite "creating a plurality of instances," but instead recite "creating a 
plurality of instances of the object " (where the object is the stored user-supplied set of 
constraints) (Claim 23) and "a database comprising a plurality of objects , each object 
comprising the set of user-supplied constraints" (Claim 31). Thus, the Final Action has 
not addressed the actual claim language, but instead addresses language that is not in the 
claims. 

Indeed, the Examiner's assertion at pages 5 and 9-10 that claims 23 and 31 
recite "iterative customer submission instances and vendor response instances" and "an 
iterative process in which one or more constraints on one of the vendor specific 
instances of the print job request object are added, removed and/or modified during each 
iteration" is perplexing. Although language similar to the first phrase was included in 
claim 1, and the latter clause was included in claim 5, appellants have cancelled those 
claims. Thus, despite the fact that claims 23 and 3 1 do not include the same language as 
claims 1 and 5, the Examiner seems to have simply copied the arguments he previously 
asserted with respect to claims 1 and 5, and merely changed the referenced claim 
numbers to 23 and 3 1 . 

Even if the Examiner had not misread the claim language, however, the 
Examiner's assertion regarding the vendors' "responses and iterative responses" is 
inconsistent with earlier his assertion that the RFQ form constitutes the claimed user- 
supplied set of constraints. One the one hand, the Examiner asserts that the RFQ is the 
stored database object, but then on the other hand, the Examiner asserts that the 
vendors' responses to the RFQ constitute the plurality of instances of the stored 
database object. The two assertions are internally inconsistent, and make no sense. 
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In addition, if a vendor's "responses and iterative responses" constitute the 
plurality of instances of the object, each instance uniquely associated with a 
corresponding vendor, then the additional claim language reciting "communicating each 
instance of the object to its corresponding associated vendor" (Claim 23), and 
"communicating] each associated object to its corresponding vendor" (Claim 31) 
would make no sense. Indeed, although Thackston discloses that each vendor 
communicates its RFQ response to the prime contractor/designer who actually solicited 
the RFQ, Thackston does not describe or suggest that any vendor communicates the 
vendor's response to itself. The reason is clear, as it would make no sense for a vendor 
to communicate to itself. 

Further, Thackston does not describe or suggest selectively displaying to the 
user the modified instances of the object individually or collectively. The Final Action 
does not discuss this issue in detail, but instead refers back to the Examiner's argument 
in the 2 June 2006 Office action (the "June 2006 Action"). The June 2006 Action, 
however, does not identify any description or suggestion in any of the references 
regarding such selective displaying. Instead, the June 2006 Action merely states that 
Hill "teaches comparing vendor specific instances in a combined view, that is 
collectively," and then concludes that it would have been obvious "to modify 
Thackston/Huberman to combine Hill's feature of comparing vendor specific instances 
in a combined view that is collectively." The, the Thackston/Huberman/Hill 
combination does not describe or suggest selectively displaying to the user modified 
instances of the object individually or collectively , but instead merely describes 
collective displaying. The Examiner's interpretation seemingly would eviscerate the 
term "selectively" from the claims. 

The other cited references are similarly inapposite. Unlike the claimed 
invention, Huberman does not describe or suggest storing a user-supplied set of 
constraints regarding a print job project in a database as an object, creating a plurality of 
instances of the object, each instance uniquely associated with a corresponding vendor, 
communicating each instance of the object to its corresponding associated vendor, 
receiving communications from the user and the vendors to iteratively modify the 
instances of the object, the modifications further constraining the print job project, or 
selectively displaying to the user the modified instances of the object individually or 
collectively. Indeed, other than pertaining to a system related to print jobs, Huberman 
seems irrelevant to the claimed invention. 
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Hill also does not describe or suggest anything regarding receiving a user- 
supplied set of constraints regarding a print job project, storing the set of constraints in a 
database as an object, creating a plurality of instances of the object, each instance 
uniquely associated with a corresponding vendor, communicating each instance of the 
object to its corresponding associated vendor, receiving communications from the user 
and the vendors to iteratively modify the instances of the object, the modifications 
further constraining the print job project, selectively displaying to the user the modified 
instances of the object individually or collectively or receiving a selection from the user 
of one of the vendors to complete the print job project. 

Thus, none of the cited references, alone or combined, describe or suggest 
the claimed invention. Accordingly, appellants respectfully request that the Board 
reverse the § 103 rejections of claims 23 and 31. Because claims 24-30 depend from 
claim 23, and claims 32-38 depend from claim 31, appellants further respectfully 
request that the Board reverse the § 103 rejections of claims 24-30 and 32-38. 



Conclusion 

For all of the foregoing reasons, Appellants respectfully request that the 
Board reverse the Examiner's rejections of claims 23-38. Appellants further 
respectfully request that the Board direct the Examiner to allow claims. 



Respectfully submitted, 




les Trosino 
afeistration No. 39,862 
Attorney for Appellants 
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CLAIMS APPENDIX 



1. 1-22. (Cancelled) 

23. (Previously Presented) A computer-based contracting method comprising: 
receiving a user-supplied set of constraints regarding a print job project; 
storing the set of constraints in a database as an object; 

creating a plurality of instances of the object, each instance uniquely 
associated with a corresponding vendor; 

communicating each instance of the object to its corresponding associated 

vendor; 

receiving communications from the user and the vendors to iteratively 
modify the instances of the object, the modifications further constraining the print job 
project; 

selectively displaying to the user the modified instances of the object 
individually or collectively; and 

receiving a selection from the user of one of the vendors to complete the 
print job project. 

24. (Previously Presented) The method of claim 23, wherein the set comprises 
a text description of the print job project. 

25. (Previously Presented) The method of claim 23, wherein the set comprises 
a list of vendors to whom the instances of the object should be communicated. 

26. (Previously Presented) The method of claim 23, wherein the set comprises 
a due date for the print job project. 

27. (Previously Presented) The method of claim 23, wherein the modifications 
comprise vendor-specified options for completing the print job project. 

28. (Previously Presented) The method of claim 27, wherein the vendor- 
specified options comprise start times or dates. 
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29. (Previously Presented) The method of claim 27, wherein the vendor- 
specified options comprise media options. 

30. (Previously Presented) The method of claim 27, wherein the vendor- 
specified options comprise pricing options. 

3 1 . (Previously Presented) A system for facilitating the formation of a contract 
for completing a print job project, the system comprising: 

a user interface adapted to receive a user-supplied set of constraints 
regarding the print job project; 

a database comprising a plurality of objects, each object comprising the set 
of user-supplied constraints, each object uniquely associated with a corresponding 
vendor; 

a plurality of vendor interfaces, each vendor interface uniquely associated 
with a corresponding vendor and adapted to communicate each associated object to its 
corresponding vendor; and 

a web server adapted to (a) transmit communications between the user and 
the vendors to iteratively modify the objects, the modifications further constraining the 
print job project, (b) selectively display to the user the modified instances of the objects 
individually or collectively; and (c) receive a selection from the user of one of the 
vendors to complete the print job project. 

32. (Previously Presented) The system of claim 3 1 , wherein the set comprises a 
text description of the print job project. 

33. (Previously Presented) The system of claim 3 1 , wherein the set comprises a 
list of vendors to whom the objects should be communicated. 

34. (Previously Presented) The system of claim 31, wherein the set comprises a 
due date for the print job project. 

35. (Previously Presented) The system of claim 3 1 , wherein the modifications 
comprise vendor-specified options for completing the print job project. 
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36. (Previously Presented) The system of claim 35, wherein the vendor- 
specified options comprise start times or dates. 

37. (Previously Presented) The system of claim 35, wherein the vendor- 
specified options comprise media options. 

38. (Previously Presented) The system of claim 35, wherein the vendor- 
specified options comprise pricing options. 
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EVIDENCE APPENDIX 
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RELATED PROCEDINGS APPENDIX 



None. 
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